Hallo, here is my question: Is it possible to insert a string into a Description of the "New Baseline"- GUI automatically within a callback function of that GUI?
I mean if I select "File -> Baseline -> New.." the GUI with the title New Baseline opens. The Description field is empty. My target is it to insert a string(eg.:"Reason:") in that Field.
What I know: The callback function of "File -> Baseline -> New.." open the file creatBaseline.dxl which calls the function #include <standard/baseline/createBaseline.inc>. I can insert my code before and after that function but of course I cant modify #include <standard/baseline/createBaseline.inc>. Is there a possibility to select and modified the Description field after the function <standard/baseline/createBaseline.inc> which create it.
Thank you for your answers,
PS: "No" is an answer too. etleg - Thu Oct 10 05:59:06 EDT 2013 |
Re: Is it possible to modify Description-field of the “New Baseline”- GUI Too bad the VooDoo meister isn't here. He'd know how to get a list of all the variables; in this case "DBE"s, and figure out which one was this description field, and then auto-populate it. But you know you'd have to patch everybody else's client install to make this useful. I have a minority opinion that that is a CM nightmare and a violation of the IT department's 12th commandment and a violation of your IBM contract. Other folks here, who's opinion I respect, believe otherwise. You could cleverly over-ride the native "createBaseline()" perm in top-context such that if the description string does not start with "Reason: " then you insert it; but I'm guessing you want the user to see "Reason: " so they know to enter an actual reason for the baseline. Perhaps you can simply put this above the #include statement:
-Louie |
Re: Is it possible to modify Description-field of the “New Baseline”- GUI llandale - Thu Oct 10 10:17:15 EDT 2013 Too bad the VooDoo meister isn't here. He'd know how to get a list of all the variables; in this case "DBE"s, and figure out which one was this description field, and then auto-populate it. But you know you'd have to patch everybody else's client install to make this useful. I have a minority opinion that that is a CM nightmare and a violation of the IT department's 12th commandment and a violation of your IBM contract. Other folks here, who's opinion I respect, believe otherwise. You could cleverly over-ride the native "createBaseline()" perm in top-context such that if the description string does not start with "Reason: " then you insert it; but I'm guessing you want the user to see "Reason: " so they know to enter an actual reason for the baseline. Perhaps you can simply put this above the #include statement:
-Louie
Hallo Louie, But what I achieved is to set a global home for every Doors client and modified createBaseline() tto get an infoBox before creating a baseline with similar information as yours.
German |
Re: Is it possible to modify Description-field of the “New Baseline”- GUI etleg - Thu Oct 10 10:53:27 EDT 2013
Hallo Louie, But what I achieved is to set a global home for every Doors client and modified createBaseline() tto get an infoBox before creating a baseline with similar information as yours.
German I have been summoned from the depth of Web Portal Programming by the call of my name ... I think you are looking for something like the below. Put it to your own include and call it using eval_ instead of the <standard/baseline/createBaseline.inc>
// prevent dxl timeout dialog
pragma runLim,0 DB dbDialog = null; // we will call them when we are ready void oldBlock (DB x) { block x; } void oldDestroy (DB x) { destroy x; } // hook into the dialog block void block (DB x) { dbDialog = x; realize x; } void destroy (DB x) { /* naah */ } #include <standard/baseline/createBaseline.inc> if (!null dbDialog) { set(versionDBE, MINOR_VER) // SAME_VER or MINOR_VER or MAJOR_VER set(descriptionDBE, "My Description!"); set(suffixDBE, "My Suffix"); oldBlock dbDialog; } You want to use eval_ because you do not want to hook block / destroy on the global DXL context that way. Maybe that helps, Regards, Mathias
|
Re: Is it possible to modify Description-field of the “New Baseline”- GUI Mathias Mamsch - Fri Oct 11 04:56:12 EDT 2013 I have been summoned from the depth of Web Portal Programming by the call of my name ... I think you are looking for something like the below. Put it to your own include and call it using eval_ instead of the <standard/baseline/createBaseline.inc>
// prevent dxl timeout dialog
pragma runLim,0 DB dbDialog = null; // we will call them when we are ready void oldBlock (DB x) { block x; } void oldDestroy (DB x) { destroy x; } // hook into the dialog block void block (DB x) { dbDialog = x; realize x; } void destroy (DB x) { /* naah */ } #include <standard/baseline/createBaseline.inc> if (!null dbDialog) { set(versionDBE, MINOR_VER) // SAME_VER or MINOR_VER or MAJOR_VER set(descriptionDBE, "My Description!"); set(suffixDBE, "My Suffix"); oldBlock dbDialog; } You want to use eval_ because you do not want to hook block / destroy on the global DXL context that way. Maybe that helps, Regards, Mathias
Hallo Mathias, first of all, it works, so thank you very much! Second, from now on I have to call you "VooDoo master"! Third I don't understand why it works. Can you please explain to me how it works with that hook. Specially what does this row do "void block (DB x) { dbDialog = x; realize x; }", and where do you got the Variable "descriptionDBE". Thank you anyway VooDoo master! German |
Re: Is it possible to modify Description-field of the “New Baseline”- GUI Mathias Mamsch - Fri Oct 11 04:56:12 EDT 2013 I have been summoned from the depth of Web Portal Programming by the call of my name ... I think you are looking for something like the below. Put it to your own include and call it using eval_ instead of the <standard/baseline/createBaseline.inc>
// prevent dxl timeout dialog
pragma runLim,0 DB dbDialog = null; // we will call them when we are ready void oldBlock (DB x) { block x; } void oldDestroy (DB x) { destroy x; } // hook into the dialog block void block (DB x) { dbDialog = x; realize x; } void destroy (DB x) { /* naah */ } #include <standard/baseline/createBaseline.inc> if (!null dbDialog) { set(versionDBE, MINOR_VER) // SAME_VER or MINOR_VER or MAJOR_VER set(descriptionDBE, "My Description!"); set(suffixDBE, "My Suffix"); oldBlock dbDialog; } You want to use eval_ because you do not want to hook block / destroy on the global DXL context that way. Maybe that helps, Regards, Mathias
So you have a scheduled task that daily queries Google for "VooDoo" and sorts on most recent instead of most relevant? Or perhaps you just use VooDoo to hear the call? lol Things are slow here, welcome back hope you can stay. And yes, how would you know to use variable "descriptionDBE"? -Louie |
Re: Is it possible to modify Description-field of the “New Baseline”- GUI etleg - Fri Oct 11 09:54:02 EDT 2013 Hallo Mathias, first of all, it works, so thank you very much! Second, from now on I have to call you "VooDoo master"! Third I don't understand why it works. Can you please explain to me how it works with that hook. Specially what does this row do "void block (DB x) { dbDialog = x; realize x; }", and where do you got the Variable "descriptionDBE". Thank you anyway VooDoo master! German Ok, as an explanation. Whenever you want to modify the behaviour of an encrypted DXL program or an include file, that you do not want to edit for whatever reason, you can do so in a couple of ways. To really do a deep modifications you need to be able to replace parts of their functionality without actually touching the file. You can do this by exploiting the simple fact, that DXL has a very simple parser, that works strictly top down. Therefore in DXL you redeclare functions, that already have been declared. void func (string s) { print "Function 1: " s "\n" } func "A" void func (string s) { print "Function 2: " s "\n" } func "B" When you redeclare a function any code from the declaration downwards, will use the new declaration of the function while all the code above the declaration will use the previous declaration. What makes this approach so powerful is, that DXL consists 99% of functions! The only statements that are not functions and DXL are variable declarations and pragmas. Even assignments are build in functions. So when you write
int a;
then this code will be interpreted as: Knowing that we can override this function (although overwriting assignment functions brings a couple of problems due to a bug in DXL, however just for interest we do it here anyway):
int ::= (int &a, int b) {
// we cannot call a = b + 1 directly, since this would bring us // into an endless recursion, so we use a skip list // put + find to assign the new value to a instead Skip sk = create(); put (sk, 0, b+1); find (sk, 0, a); delete sk return b+1 } // from here integer assignments will now use our new function int a a = 10 print a // prints 11 // Note that assignment in declaration does NOT use the perm // int b = 10; print b; --> will return 10 Ok, so knowing this, you can see, that you can change ANY behaviour even inside an encrypted program, by just placing the right redeclarations in front of the code. The problem with the createBaseline.inc script is, that it created a GUI using code like this:
DB my_secret_GUI_variable; So what we did to modify the behaviour is, to replace void block (DB) and void destroy(DB) by dummy functions, so that the program will create the GUI but not block and destroy it, but just run to the end. Then we made our modifications to the GUI elements and then called block and destroy from some other functions that were placed BEFORE the redeclared functions (meaning they would call the original block / destroy functions). This technique is what I normally call "hooking" a function. So knowing this you can take another look at the code above and it should make you understand. Regarding your question on how to know the variables inside a script, there is more than one possibility. The most comfortable is of course to decrypt it. Obviously DOORS does it and if the client can do it, anyone can do it (after all DOORS has always favoured security by obscurity). Fortunately IBM makes that very easy by providing us the crypt.dll right with the DOORS client. The second way for all people who do not like experimenting with DLLs is to use for example DXL tracing. If you evaluate the following code:
startDXLTracing_ ("C:\\temp\\log.txt")
#include <standard/baseline/createBaseline.inc> // end your client afterwards, or manually turn of tracing by executing: stopDXLTracing_ () then look at the created 253kb 'log.txt' file, power up your Excel, paste the contents inside it, make a filter for "contains createBaseline", you get a 153 lines of code in which you can spot the variable names normally pretty easily. Hope that helps, regards, Mathias |
Re: Is it possible to modify Description-field of the “New Baseline”- GUI llandale - Fri Oct 11 11:43:25 EDT 2013 So you have a scheduled task that daily queries Google for "VooDoo" and sorts on most recent instead of most relevant? Or perhaps you just use VooDoo to hear the call? lol Things are slow here, welcome back hope you can stay. And yes, how would you know to use variable "descriptionDBE"? -Louie I received the call through another "daemon" still reading this forum ... Thought it might be funny to react to the term "VooDoo meister" ;-) In fact I still read in the forum from time to time - however I am disappointed that the Developerworks guys seem to either not be able or not willing to fix the problem with the legacy code. When I asked them about this issue and told them that people like me spent 100s of hours in teaching IBM products to other people they wrote me back " ... we are working on this as a high priority issue ... we never intended to destroy stuff ... " ... However that has been a month ago and of course this issues have been reported to them much earlier. So I am not really motivated to work in this forum anymore, until this is fixed. As far as I can see I am not the only one who stopped reading in / writing to the forum - the activity in the last months was not really big. Regards, Mathias |
Re: Is it possible to modify Description-field of the “New Baseline”- GUI Mathias Mamsch - Sat Oct 12 10:13:06 EDT 2013 Ok, as an explanation. Whenever you want to modify the behaviour of an encrypted DXL program or an include file, that you do not want to edit for whatever reason, you can do so in a couple of ways. To really do a deep modifications you need to be able to replace parts of their functionality without actually touching the file. You can do this by exploiting the simple fact, that DXL has a very simple parser, that works strictly top down. Therefore in DXL you redeclare functions, that already have been declared. void func (string s) { print "Function 1: " s "\n" } func "A" void func (string s) { print "Function 2: " s "\n" } func "B" When you redeclare a function any code from the declaration downwards, will use the new declaration of the function while all the code above the declaration will use the previous declaration. What makes this approach so powerful is, that DXL consists 99% of functions! The only statements that are not functions and DXL are variable declarations and pragmas. Even assignments are build in functions. So when you write
int a;
then this code will be interpreted as: Knowing that we can override this function (although overwriting assignment functions brings a couple of problems due to a bug in DXL, however just for interest we do it here anyway):
int ::= (int &a, int b) {
// we cannot call a = b + 1 directly, since this would bring us // into an endless recursion, so we use a skip list // put + find to assign the new value to a instead Skip sk = create(); put (sk, 0, b+1); find (sk, 0, a); delete sk return b+1 } // from here integer assignments will now use our new function int a a = 10 print a // prints 11 // Note that assignment in declaration does NOT use the perm // int b = 10; print b; --> will return 10 Ok, so knowing this, you can see, that you can change ANY behaviour even inside an encrypted program, by just placing the right redeclarations in front of the code. The problem with the createBaseline.inc script is, that it created a GUI using code like this:
DB my_secret_GUI_variable; So what we did to modify the behaviour is, to replace void block (DB) and void destroy(DB) by dummy functions, so that the program will create the GUI but not block and destroy it, but just run to the end. Then we made our modifications to the GUI elements and then called block and destroy from some other functions that were placed BEFORE the redeclared functions (meaning they would call the original block / destroy functions). This technique is what I normally call "hooking" a function. So knowing this you can take another look at the code above and it should make you understand. Regarding your question on how to know the variables inside a script, there is more than one possibility. The most comfortable is of course to decrypt it. Obviously DOORS does it and if the client can do it, anyone can do it (after all DOORS has always favoured security by obscurity). Fortunately IBM makes that very easy by providing us the crypt.dll right with the DOORS client. The second way for all people who do not like experimenting with DLLs is to use for example DXL tracing. If you evaluate the following code:
startDXLTracing_ ("C:\\temp\\log.txt")
#include <standard/baseline/createBaseline.inc> // end your client afterwards, or manually turn of tracing by executing: stopDXLTracing_ () then look at the created 253kb 'log.txt' file, power up your Excel, paste the contents inside it, make a filter for "contains createBaseline", you get a 153 lines of code in which you can spot the variable names normally pretty easily. Hope that helps, regards, Mathias Hallo,
thank you for the explanation, now I got the idea of that script and the "hooking" strategy. I must say this is a piece of great work and that "hooking" is freaking awesome. Through your description I have a new OP: decrypting of doors ".inc"- files with crypt.dll
The fact that :"So I am not really motivated to work in this forum anymore" is really sad I hope they will fix that bug fast, so you can grow your motivation.
Thank you anyway, German |